I wish you had reached out to me first. I have a nearly complete PR of my own coming, just missing one BlockingPortal fix.

This PR is quite different from what I have locally. I will push my changes and make a PR tomorrow so we can compare notes.

Sure thing!

And sorry, I did most of the work on a long flight a couple of weeks ago without internet (and I was mostly offline for the past two weeks). And the main part of my work was just porting my tests from the other Trio PR.

If we can check that the tests/use cases pass with your PR I'm perfectly fine with closing mine. 🙂

Also feel free to just copy paste anything you find useful here in this PR, no need to worry about "commit attributions" or anything like that. 🤓

Your PR seems to handle things better than mine. I had some ugly workarounds for trio but I'd rather have trio solve those problems on their end while I deal with asyncio here. I'll look into merging our efforts into one conclusive PR, with BlockingPortal also covered and without the trio workarounds.

Awesome, thank you! Feel free to close this PR whenever you consider it appropriate.

I have my own PR now (#390) which incorporates tricks from this one. We still need trio to fix the problem on their end.

One unresolved issue is what sniffio.current_async_library() should give in a worker thread. In my opinion it should raise AsyncLibraryNotFoundError since it's not in an event loop thread.

I'm +1 on AsyncLibraryNotFoundError in principle.

On the other hand, the cases where that actually matters (i.e. you use a library within the thread that uses sniffio) are likely to be few and far between. Thus I'd be OK with requiring the user to explicitly clear sniffio's state if that's required.

Looking at @tiangolo 's trio PR, I see that it is setting the current async library to None, but my test still fails on trio:

async def test_asynclib_detection() -> None:
    with pytest.raises(sniffio.AsyncLibraryNotFoundError):
        await to_thread.run_sync(sniffio.current_async_library)

What I think is going on here (correct me if I'm wrong) is: the cached name of the current async library is voided, but the trio token is still present in the context so sniffio's detection picks that up and declares that the worker thread is running on the trio event loop.

? sniffio doesn't check for Trio. Like, at all. Trio explicitly sets sniffio's contextvar.

Right. So why is this happening then?

I suspect that to_thread.run_sync uses some context to run the thread … just not the one you're calling to_thread.run_sync from. As Trio's thread engine does thread caching AFAIR, that seems somewhat likely at least.

Ahh...it's anyio that's setting sniffio's contextvar in the worker thread. I think that's a no-no, and I need to use my own context for that instead.

Removed the lines that set the sniffio cvar; no ill effects noted in the test suite. The PR is now ready, once trio is. We should continue the discussion over at #390.